实用帖丨多校区教室直播平台设计方案

在疫情防控常态化大背景下，为保障“停课不停教，停课不停学”的教学要求，“线上+线下”相结合的教学模式被广泛认可，而在这种教学模式下，需要全部教室支持在线直播功能。

为了满足多校区大规模教室常态直播，本文设计了一套多校区大规模教室常态直播平台，依靠传统教室现有的摄像头和编码器设备，通过软件方式进行视频流动态按需采集，无需专用录播主机，具有部署灵活、投入成本低、维护简单、高可扩展和高可靠的优势。

基于SRS构建的多校区分布式直播集群，利用源站和边缘分离的直播架构，满足大规模直播推流和拉流需求。用户通过多级负载均衡策略实现就近访问，根据终端的不同，提供RTMP、HTTP-FLV、HLS等多协议的访问。

01

关键技术

流媒体技术

典型的流媒体架构如图1所示，主要包括推流端、流媒体服务器和拉流端。

图1 流媒体系统架构

推流端一般为OBS、FFmpeg等推流软件或者摄像机，编码盒子等设备通过推流协议将编码后的音视频流推送到流媒体服务器。

目前主流的流媒体服务器为Nginx-rtmp、SRS、EasyDarwin和Red5等。流媒体服务器将视频流进行解码封装之后，拉流端通过流媒体协议从流媒体服务器获取数据流。拉流端一般为PC端或者移动设备。不同的拉流设备对流媒体协议的兼容性不同。

目前用于推流和拉流的主要流媒体协议为RTMP、HTTP-FLV和HLS，表1为三种流媒体协议在传输协议、数据格式、延迟和兼容性方面的对比。

表1 流媒体协议对比

通过对比分析，RTMP由于TCP的可靠性以及延迟低的特性，更适用于推流。从防火墙通过性和前端播放兼容性考虑，HTTP-FLV和HLS更适合拉流。HTTP-FLV适合PC端和移动App，HLS适合原生iOS。对时延有要求的场景也可以使用RTMP作为拉流协议，但是播放器需要集成Flash。

SRS开源流媒体服务器

SRS是一个高效、稳定、简单的开源流媒体服务器，支持RTMP、HTTP-FLV、HLS、WebRTC、SRT等视频传输协议。

SRS虽然是单进程模型，但是性能却是Nginx-rtmp的三倍左右，同时可以通过源站+边缘集群架构或者通过SO_REUSEPORT端口复用实现性能的水平扩展。

SRS提供丰富的管理接口用于应用集成，例如对客户端的视频发布和播放等操作进行身份鉴权认证。

表2 SRS HTTP事件回调

SRS支持如表2所示的HTTP事件回调功能，相关流媒体事件发生后，会触发SRS调用API接口并进行数据传输。同时可以通过HTTP API接口对SRS服务器状态、服务配置、视频流、客户端等进行管理和监控。

02

平台设计与实现

平台架构

本文设计与实现的基于SRS的多校区大规模教室常态直播平台整体架构如图2所示。

图2 常态直播平台整体架构

直播平台主要由集中管理控制、分布式动态推流、分布式直播集群和多级负载均衡组成。

集中管理控制组件，通过消息队列动态调度分布式动态推流组件，将分布在多个校区的教室内摄像头和音视频编码器，通过标准的RTSP流媒体协议推送到分布式直播集群。

分布式直播集群接收输入的RTSP流后，根据策略进行转码、录制和分发。不同终端的用户分别使用RTMP、HTTP-FLV和HLS通过多级负载均衡组件观看视频直播。

集中管理控制组件与其他组件之间通过HTTP RESTful API和消息队列机制进行通信。

分布式动态推流组件

本文借鉴之前教室常态录播的研究成果，教室内不再额外配置录播一体机，统一由后台软件进行教室视频流的抓取和推送。

这样不仅节约了建设和维护成本，同时将多路视频流同时呈现给用户，用户可根据自身需求自行选择和切换，而不是固定的导播画面或者分屏画面。

每间教室同时抓取多路音视频流并推送到直播平台，对推流组件的采集性能和直播组件的接入性能带来了更高的挑战。

为了应对这个挑战，本文实现了多校区分布式动态推流组件，推流组件由分布在多个校区的推流服务组成，实现动态的直播推流。

集中管理控制组件根据教学任务自动生成直播任务，或者通过管理员手动添加直播任务。直播任务生成后自动发布到异步消息队列中。

推流采取本地推流的策略，即正常情况下推流组件只获取本地教室的视频推流任务。只有当集中管理控制组件发现某个校区暂时没有可用推流服务时，才会动态调度推流任务到其他校区的推流组件实现跨校区的推流。

目前，随着疫情的变化，直播需求也在不断变换，某些课程可能存在一段时间无人观看的情况。如果长时间保持所有教室都是直播状态，一方面浪费服务器资源和带宽；另一方面对摄像头等前端编码设备也会带来额外压力。

本文利用直播平台的HTTP回调功能和直播流信息查询功能，实现视频流无人观看后自动停止推流，有人观看就立即推流并分发的动态推流机制。

分布式动态推流主要由live_stream_create

和live_stream_monitor组成。

live_stream_create如图3所示。

图3 分布式动态推流算法示意

推流服务监听消息队列，获取新的直播任务使用live_stream_create进行直播流创建和监控，传递的参数为直播教室ID、开始直播的时间和直播时长。程序首先调用issue_live_stream函数获取摄像头视频流并推送到直播平台开始直播。

同时，根据直播创建程序返回的stream_id，定期调用get_stream_info函数来获取直播流的观看信息。如果当前直播流没有用户观看的时间超过预先设置的IdelThreshold空闲阈值，就会调用stop_live_stream函数停止直播。

为了防止因短期无人观看而停止的直播流后续有人继续观看，管理服务器利用直播平台的HTTP回调功能监听直播平台中每个直播流的事件，维护直播平台当前正在直播的流信息PublicStreams。监控程序live_stream_monitor如图4所示。

图4 分布式动态推流-视频流监控算法示意

监控程序live_stream_monitor调用listen_callback来监听直播流事件。

如果获取直播流的事件是来自推流端的on_public或者un_public，意味着有直播流新建或者直播流停止，那么使用add_publicstream和delete_publicstream来更新PublicStreams。

如果事件是来自拉流端的on_play，同时该直播流不在PublicStreams中，那么就需要调用live_stream_check检查该直播流是否在直播任务中。

如果该直播流属于正常的直播任务并且还在直播有效期内，那么说明该直播流是由于长时间没人观看而临时关闭的。此时，需要更新public_duration之后并调用前面的算法1中的live_stream_create进行直播流创建并立即开始直播。

分布式直播集群

为了满足大规模教室常态并发高清直播和大规模终端用户并发访问，基于SRS流媒体服务器设计实现了多校区分布式直播集群。

为了提升直播平台的直播流接入能力和播放能力，直播集群采用类似CDN的源站+边缘的架构进行多校区分布式部署，如图5所示。

图5 分布式直播集群

分布式直播集群中的SRS实例分为源站和边缘两种角色，源站实例专注于接收来自分布式推流组件的直播流；边缘实例专注于处理大规模终端用户的播放请求。

边缘实例根据用户请求的直播流动态访问源站实例获取直播流，然后分发视频流到最终用户，使用户通过多种协议观看课堂直播。在多校区分布式部署下，每个校区根据教室数量单独部署多个源站实例和边缘实例组成校区直播集群。

校区直播集群中多个源站实例构成源站服务组，接收来自分布式动态推流组件推送的教室视频直播流，源站服务组根据并发直播的教室数量动态扩展，提升平台支持并发推流的能力。

校区直播集群中多个边缘实例构成边缘服务组，边缘服务组根据并发终端用户进行动态扩展，提升平台的并发视频播放能力。

源站和边缘服务组中的所有实例之间可以实现服务的负载均衡和故障切换。源站边缘解耦的架构使得可以根据各个校区教室数量和观看人数分别动态扩展SRS实例。

为了降低直播延迟和缓解跨校区之间网络带宽压力，学校采用本地推流的策略，分布式动态推流组件优先将教室直播视频流推送到与该教室位于同一校区的本地直播集群的源站服务组，多个源站服务组的实例间通过HTTPAPI共享直播流信息。

边缘实例采用RTMP协议进行直播流回源，为终端用户提供RTMP、HTTP-FLV和HLS的直播流。在多校区部署下，直播流回源分为本地回源和远端回源，边缘实例从同一校区直播集群中的源站实例拉取直播流称为本地回源，从位于其他校区直播集群的源站实例拉取直播流称为远端回源。

本地回源和远端回源使得终端用户从任意一个校区的直播集群的边缘实例请求指定直播流时，最终都可以通过RTMP重定向到拥有该直播流的源站实例进行直播回源。直播回源流程如图6所示。

图6 直播回源流程

多级负载均衡

分布式直播平台中边缘实例给终端用户提供RTMP和HTTP-FLV直播流。在本文的实例中，每个校区存在一个边缘服务组，每个边缘服务组存在多个边缘实例。

为了实现边缘服务组之间负载均衡同时支持故障自动切换来消除单点故障，本系统设计了多级负载均衡机制，如图7所示。多级负载均衡包括SO_REUSEPORT、LVS和智能DNS。

图7 多级负载均衡

1.SO_REUSEPORT

SRS是单进程模型，为了充分利用多核服务器的性能，每个服务器根据CPU的核心数运行多个SRS边缘实例；为了防止实例在CPU之间切换带来额外开销，每个实例利用taskset将实例绑定在特定CPU核心上运行。

所有SRS实例使用SO_REUSEPORT选项可以监听在服务器的相同端口下，操作系统内核将请求均衡地分散到每个SRS实例。

2.LVS

每个校区的边缘服务组中一般部署多台服务器来提升并发和可靠性。我们使用LVS实现边缘服务组中服务器之间的负载均衡和容错。

每个边缘服务组对外使用VIP提供服务，为了防止LVS成为性能瓶颈，则采用LVS-DR模式。

LVS只把用户访问请求分发到SRS实例，直播流数据不经过LVS，而是直接由SRS实例返回给终端用户。

3.智能DNS

不同校区的边缘服务组使用不同的VIP对外提供服务，终端用户使用统一的域名观看直播。智能DNS根据调度策略将域名解析为特定校区的VIP，进而将用户请求均衡到每个VIP。

默认的调度策略是优先将校内用户调度到同一校区的边缘服务组VIP上，实现直播流的就近访问，减少远端回流。这样，一方面降低直播延迟，另一方面防止大量远端回源占用跨校区带宽。

同时，管理服务器会实时跟踪各校区边缘服务组状态，如果某个校区的边缘服务组负载很大或者故障，通过动态调整DNS解析策略，将用户调度到其他边缘服务组，提升系统的可靠性。

03

部署实践

西安交通大学多校区大规模教室常态直播平台中SRS服务器以虚拟机形式分别部署在兴庆、雁塔和创新港三个校区，实现分布在三个校区700间教室的常态直播，满足本科和研究生课程常态直播的需求。

直播平台根据教室数量和直播观看人数动态调整虚拟机数量以及SRS不同角色实例的数量。通过SRS Bench进行压力测试，测试结果显示在单路直播流2Mb/s的情况下，单SRS实例可以最大支持不同路直播推流1000路，不同路最大拉流1400路。根据每个校区实际课程并发直播数和并发视频观看人数，实际部署情况见表3。

表3 各校区部署情况

同时，将直播平台嵌入到我校现有的课程平台中，通过课表对接、手动设置和API接口等多种方式分别实现教室直播控制。

学生通过统一身份认证登录成功之后，根据权限观看所选课程直播视频。直播视频采用多路视频画面（教师授课、板书特写、学生听课、计算机桌面等）同时播放，并且根据权限进行灵活切换和动态布局，如图8所示。

图8 课程直播页面

其中，学生听课画面只对教务、教学督导人员开放。直播同时支持RTMP、FLV、HLS多协议来适应不同平台、不同网络环境和不同延迟需求的场景。

通过跨校区分布式直播平台有效保障了疫情常态化环境下国际留学生、隔离学生、跨校区选课等不能参加线下授课学生的课程在线直播，同时基于直播平台构建教学督导平台，全面掌握现场教学实况，无须干扰教师课堂教学，实现线上精准听课和督导。

为满足高校疫情常态化期间“线上+线下”相结合的教学模式。本文设计实现了多校区大规模教室常态直播平台，满足大规模教室视频直播需求。

通过分布式动态视频推流来实现教室视频的采集和推送，同时构建源站+边缘架构的直播平台，满足大规模视频流的并发直播需求，并且同时支持RTMP、HTTP-FLV和HLS，满足各种平台的不同要求。

最后，提出了一种多级负载平衡机制，以提高系统的整体性能和可靠性，满足大规模用户的并发访问。

作者：王强、崔靖茹、董凡、安宁刚（西安交通大学网络信息中心）

责编：陈永杰

投稿、转载或合作，请联系：[e-mail]

往期推荐

欢迎分享、在看与点赞

积极留言，更会有意外惊喜~